Skip to content

Conversation

@DDShantanuBadmanji
Copy link

@DDShantanuBadmanji DDShantanuBadmanji commented Oct 1, 2025

Delete this text and replace it with a detailed description of your change. The
PR title and body will become the squashed commit message.

If you would like to tag individuals, add some commentary, upload images, or
include other supplemental information that should not be part of the eventual
commit message, please use a separate comment.

If applicable, please include a summary of the testing strategy (including
rationale) for the proposed change. Unit and/or integration tests are expected
for any behavior change and system tests should be considered for larger
changes.

Summary by CodeRabbit

  • New Features

    • Config provider metrics are now exposed in Connect when providers are monitorable, with clear tags for config, class, and provider.
  • Refactor

    • Unified handling of config providers via a plugin-based approach across clients and Connect; no configuration changes required.
  • Documentation

    • Expanded guidance for config providers on metrics support and default metric tags.
  • Tests

    • Added coverage for monitorable config providers and metrics; updated existing tests accordingly.
  • Chores

    • Minor formatting/comment update to development environment file.

@coderabbitai
Copy link

coderabbitai bot commented Oct 1, 2025

Caution

Review failed

The pull request is closed.

Walkthrough

Config providers are refactored to be handled as Plugin-wrapped instances across core config, Connect runtime, and MirrorMaker. Constructors, fields, and method signatures are updated accordingly. Metrics support is integrated for monitorable providers. Tests are adjusted to use Plugin wrappers and include new coverage for monitorable provider metrics.

Changes

Cohort / File(s) Summary of edits
Dev env formatting
Vagrantfile
Added a blank line and a comment before VAGRANTFILE_API_VERSION; no behavioral change.
Core config provider pluginization
clients/src/main/java/org/apache/kafka/common/config/AbstractConfig.java, clients/src/main/java/org/apache/kafka/common/config/ConfigTransformer.java, clients/src/main/java/org/apache/kafka/common/config/provider/ConfigProvider.java
Switched provider handling to Plugin<ConfigProvider> across instantiation, storage, transformation, and closing. Updated constructor/field signatures in ConfigTransformer. Added Javadoc to ConfigProvider about Monitorable metrics.
Clients tests update
clients/src/test/java/org/apache/kafka/common/config/ConfigTransformerTest.java
Wrapped test providers with Plugin.wrapInstance(...); replaced Collections.singletonMap(...) with Map.of(...); adapted assertions/workflow accordingly.
Connect runtime provider pluginization + metrics
connect/runtime/src/main/java/org/apache/kafka/connect/runtime/Worker.java, connect/runtime/src/main/java/org/apache/kafka/connect/runtime/WorkerConfigTransformer.java, connect/runtime/src/main/java/org/apache/kafka/connect/runtime/isolation/Plugins.java, connect/mirror/src/main/java/org/apache/kafka/connect/mirror/MirrorMakerConfig.java
Migrated from direct ConfigProvider to Plugin<ConfigProvider> across initialization, storage, transformation, and cleanup. Plugins.newConfigProvider(...) now returns Plugin<ConfigProvider> and accepts Metrics; computes provider prefix internally; wraps provider with metrics metadata. Adjusted call sites and close messages.
Connect tests (transformer, worker, plugins)
connect/runtime/src/test/java/org/apache/kafka/connect/runtime/WorkerConfigTransformerTest.java, connect/runtime/src/test/java/org/apache/kafka/connect/runtime/WorkerTest.java, connect/runtime/src/test/java/org/apache/kafka/connect/runtime/isolation/PluginsTest.java
Updated tests to use Plugin<ConfigProvider> and Map.of(...). Added tests verifying MonitorableConfigProvider metrics propagation and tags. Introduced a custom monitorable provider subclass for metrics assertions.
Monitorable provider test implementation
clients/src/test/java/org/apache/kafka/common/config/provider/MonitorableConfigProvider.java
New test class implementing ConfigProvider and Monitorable; registers a constant-value plugin metric; stubbed get/close; configurable via configure(Map).

Sequence Diagram(s)

sequenceDiagram
  autonumber
  actor App as Application
  participant AC as AbstractConfig
  participant CT as ConfigTransformer
  participant PP as ProviderPlugins (Map<String, Plugin<ConfigProvider>>)
  participant CP as ConfigProvider

  App->>AC: resolveConfigVariables(configs)
  AC->>AC: instantiateConfigProviders() -> PP
  AC->>CT: new ConfigTransformer(PP)
  App->>CT: transform(configs)
  CT->>PP: lookup providerPlugin by name
  alt provider found
    CT->>PP: providerPlugin.get()
    PP-->>CT: CP
    CT->>CP: get(path, keys)
    CP-->>CT: ConfigData
    CT-->>App: transformed configs
  else provider missing
    CT-->>App: unchanged or error per logic
  end
  AC->>PP: closeQuietly each provider plugin
Loading
sequenceDiagram
  autonumber
  actor Admin as Connect Worker Startup
  participant W as Worker
  participant Pl as Plugins
  participant M as Metrics
  participant PPl as Plugin<ConfigProvider>
  participant WCT as WorkerConfigTransformer

  Admin->>W: start()
  W->>Pl: newConfigProvider(config, providerName, PLUGINS, M)
  Pl->>Pl: compute providerPrefix
  Pl->>Pl: instantiate ConfigProvider
  Pl->>PPl: Plugin.wrapInstance(provider, metadata:{provider})
  Pl-->>W: PPl
  W->>WCT: new WorkerConfigTransformer(W, {name -> PPl})
  note over WCT: Transformer holds Plugin-wrapped providers
  Admin-->>W: running
Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~60 minutes

Poem

I hop through configs, ears held high,
Wrapping providers as plugins fly.
Metrics twinkle, tags in line,
Monitorable carrots taste divine.
With tidy tests and cleaner streams,
I bound through code—transforming dreams. 🥕✨

✨ Finishing touches
  • 📝 Generate Docstrings
🧪 Generate unit tests
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch clone-KAFKA-18894

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between ed79212 and 5989a26.

📒 Files selected for processing (13)
  • Vagrantfile (1 hunks)
  • clients/src/main/java/org/apache/kafka/common/config/AbstractConfig.java (4 hunks)
  • clients/src/main/java/org/apache/kafka/common/config/ConfigTransformer.java (3 hunks)
  • clients/src/main/java/org/apache/kafka/common/config/provider/ConfigProvider.java (1 hunks)
  • clients/src/test/java/org/apache/kafka/common/config/ConfigTransformerTest.java (5 hunks)
  • clients/src/test/java/org/apache/kafka/common/config/provider/MonitorableConfigProvider.java (1 hunks)
  • connect/mirror/src/main/java/org/apache/kafka/connect/mirror/MirrorMakerConfig.java (2 hunks)
  • connect/runtime/src/main/java/org/apache/kafka/connect/runtime/Worker.java (1 hunks)
  • connect/runtime/src/main/java/org/apache/kafka/connect/runtime/WorkerConfigTransformer.java (3 hunks)
  • connect/runtime/src/main/java/org/apache/kafka/connect/runtime/isolation/Plugins.java (3 hunks)
  • connect/runtime/src/test/java/org/apache/kafka/connect/runtime/WorkerConfigTransformerTest.java (5 hunks)
  • connect/runtime/src/test/java/org/apache/kafka/connect/runtime/WorkerTest.java (5 hunks)
  • connect/runtime/src/test/java/org/apache/kafka/connect/runtime/isolation/PluginsTest.java (4 hunks)

Warning

There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure.

🔧 ast-grep (0.39.5)
connect/runtime/src/test/java/org/apache/kafka/connect/runtime/WorkerTest.java

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@refacto-visz
Copy link

refacto-visz bot commented Oct 1, 2025

⚠️ No Active Seat

The user @DDShantanuBadmanji does not have an active seat allocated for code reviews.

Please contact your organization admin to assign a seat or upgrade your subscription.

@gemini-code-assist
Copy link

Summary of Changes

Hello @DDShantanuBadmanji, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a foundational change to how ConfigProvider instances are handled within the Kafka ecosystem. By wrapping ConfigProviders in a generic Plugin object, the system gains improved capabilities for standardized lifecycle management and enables automatic metrics registration for providers that implement the Monitorable interface. This enhancement aims to provide better observability and a more robust plugin architecture for configuration management.

Highlights

  • Plugin Wrapper for ConfigProviders: ConfigProvider instances are now consistently wrapped within a generic 'Plugin' object across the codebase. This change standardizes the management and lifecycle of configuration providers.
  • Metrics Integration for ConfigProviders: ConfigProvider implementations can now register metrics by implementing the 'Monitorable' interface. The system automatically adds relevant tags ('config', 'class', 'provider') to these metrics, enhancing observability.
  • Refactored ConfigProvider Instantiation: The logic for instantiating ConfigProviders in key components like AbstractConfig, MirrorMakerConfig, Worker, and WorkerConfigTransformer has been updated to leverage the new Plugin wrapper, ensuring consistent plugin handling.
  • Enhanced Test Coverage: New test cases have been introduced and existing ones updated to validate the correct behavior of the Plugin wrapper and the new metrics registration for MonitorableConfigProviders.
  • Code Modernization: Several test files have been updated to use 'Map.of()' instead of 'Collections.singletonMap()' or 'Collections.emptyMap()', adopting more modern Java syntax.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

@DDShantanuBadmanji
Copy link
Author

/refacto-test

Copy link

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request refactors the handling of ConfigProvider to introduce a Plugin wrapper, enabling metrics for monitorable providers. The changes are well-implemented across the client and connect modules, with corresponding updates to tests. I've found one area for improvement regarding redundant configuration transformation in MirrorMakerConfig, which could be simplified for better efficiency. Overall, this is a good enhancement.

Comment on lines 270 to 287
Map<String, String> transform(Map<String, String> props) {
// transform worker config according to config.providers
List<String> providerNames = configProviders();
Map<String, ConfigProvider> providers = new HashMap<>();
Map<String, Plugin<ConfigProvider>> providerPlugins = new HashMap<>();
for (String name : providerNames) {
ConfigProvider configProvider = plugins.newConfigProvider(
Plugin<ConfigProvider> configProviderPlugin = plugins.newConfigProvider(
this,
CONFIG_PROVIDERS_CONFIG + "." + name,
Plugins.ClassLoaderUsage.PLUGINS
name,
Plugins.ClassLoaderUsage.PLUGINS,
null
);
providers.put(name, configProvider);
providerPlugins.put(name, configProviderPlugin);
}
ConfigTransformer transformer = new ConfigTransformer(providers);
ConfigTransformer transformer = new ConfigTransformer(providerPlugins);
Map<String, String> transformed = transformer.transform(props).data();
providers.values().forEach(x -> Utils.closeQuietly(x, "config provider"));
providerPlugins.values().forEach(x -> Utils.closeQuietly(x, "config provider plugin"));
return transformed;
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

This transform method appears to be redundant and leads to inefficiency. Config providers are instantiated, used, and closed here, but the configurations produced by clientConfig and workerConfig are later passed to AbstractConfig subclasses (MirrorClientConfig and WorkerConfig respectively), which perform the same transformation step again.

This means config providers are initialized twice. The second transformation will likely be a no-op on already-resolved values, but the setup and teardown of providers is unnecessary overhead.

It would be more efficient to remove this transform method and the calls to it in clientConfig and workerConfig. AbstractConfig's constructor will handle the variable resolution automatically.

@refacto-visz
Copy link

refacto-visz bot commented Oct 1, 2025

⚠️ No Active Seat

The user @DDShantanuBadmanji does not have an active seat allocated for code reviews.

Please contact your organization admin to assign a seat or upgrade your subscription.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants